I like the laziness approach in general (we have a lot of reflected members that are never normally used but consume memory), but it hasn't gone far enough yet to resolve the serialisation issues. Have a look at the extra assertions I've added to ContinuationsApiTest in #2249 to see where we can hit a problem with function identity. There's also some existing and deeply weird behaviour on these classes associated with setting additional properties.

I think the solution might be to make JavaMembers more pure, i.e. it only supplies the necessary NativeJava* objects, but never stores them itself (this would allow the generic types to be tightened up), and would never itself be serialised. We would then change classes like NativeJavaObject to be the ones that hold the cached NativeJavaMethods etc. in their slot maps, and these could then be serialised in the normal way.

This would require a little work to handle sealed cases correctly, and raises a question of what the initial state of the property map should be. Maybe we should initially gather a list of reflected member names, and populate them with values lazily?

... hit a problem with function identity

It seems this can be fixed by implementing a proper equals(...) for NativeJavaMethod

... also some existing and deeply weird behaviour on these classes associated with setting additional properties.

I don't quite understand this, is the code below a valid example of this issue?

let obj1, obj2; // instances of the same java class

obj1.someMethod.someProp = 42
obj2.someMethod.someProp // gives 42

My next step will probably be introduce some intermediate representation, between ExecutableBox and NativeJavaMethod, and eventually get rid of NativeJavaMethod within JavaMembers

... hit a problem with function identity

It seems this can be fixed by implementing a proper equals(...) for NativeJavaMethod

NativeJavaMethod is a subclass of BaseFunction, it is mutable, I can add properties to it, change the prototype, whatever, you have to honour identity here.

... also some existing and deeply weird behaviour on these classes associated with setting additional properties.

I don't quite understand this, is the code below a valid example of this issue?

let obj1, obj2; // instances of the same java class

obj1.someMethod.someProp = 42
obj2.someMethod.someProp // gives 42

Yeah. If you look at NativeJavaObject it has a put implementation that looks like this:

    @Override
    public void put(String name, Scriptable start, Object value) {
        // We could be asked to modify the value of a property in the
        // prototype. Since we can't add a property to a Java object,
        // we modify it in the prototype rather than copy it down.
        if (prototype == null || members.has(name, false))
            members.put(this, name, javaObject, value, false);
        else prototype.put(name, prototype, value);
    }

We should probably treat these objects as sealed, i.e. you cannot add new properties to them, even you can edit existing ones.

My next step will probably be introduce some intermediate representation, between ExecutableBox and NativeJavaMethod, and eventually get rid of NativeJavaMethod within JavaMembers

I think we're in agreement here that NativeJavaMethod has no place in JavaMembers, the question is how does NativeJavaObject hold on to resolved methods, and how can you ensure the identity of those?

Heh @ZZZank, would you be open to a PR to make JavaMembers a pure cache for member boxes and similar, and never serialised? I'm happy to work on it if so.

#2298 , though I'm not sure whether NativeJavaMethod reference should also be stripped, sinve we will never mutate this